REMARKS 

Applicants have carefully reviewed the arguments presented in the Office Action and 
respectfully request entry of the amendment and reconsideration of the claims in view of the 
remarks presented below. 

Claims 1, 7, and 13 have been amended. Claims 19-23 have been withdrawn. Thus, 
claims 1-18 are pending in the application. 

Claims 1-18 were provisionally rejected on the ground of nonstatutory double patenting 
over claims 115-121 of co-pending Application No. 90/626577, as filed on 5/18/2007. A 
terminal disclaimer executed by Zafar Kahn, President of RPOST International, the assignee and 
thus owner of 100 percent interest in the instant application, is being filed herewith. Applicant 
thus respectfully submits that this rejection is now moot, and requests that it be withdrawn. 

Claims 1-6 were rejected under 35 U.S.C. 102(b) as being anticipated by Barkan 
(International Pub. No. WO 98/17042. Applicant respectfully traverses this rejection. 

It is axiomatic that, to anticipate a claim, a reference must disclose each and every 
element or step of the claim. Barkan does not teach, or even suggest, adding a pixel for 
indicating the opening of the message at the recipient to the message at the server, transmitting 
the message from the server to the recipient, the message including the pixel for indicating the 
opening of the message at the recipient at the server, and transmitting the message from the 
recipient to the server, including the pixel for indicating the opening of the message at the 
recipient, when the message is opened at the recipient, as is claimed in amended claim 1 . 

Although the Examiner states that Barkan "teaches a method where a recipient receives a 
transmitted message that includes a pixel for indicating the opening of the message," the word 
pixel, or any structure that one skilled in the art would understand to be a pixel, cannot be found 
within Barkan. Applicant requests that the Examiner identify exactly where Barkan teaches such 
a pixel. 

However, besides the pixel, there are other elements of amended claim 1 that are simply 
not to be found within Barkan. These differences can clearly be seen from pages 29-34 of 
Barkan, which are the pages cited by the Examiner as showing all of the elements of claim 1 . 
For example, amended claim 1 recites that the pixel is added at the server before the message is 
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sent to the recipient. It should be noted that the pixel indicates whether the message is opened by 
the recipient; it is not a "key" that is used to enable the message to be opened. Further, as recited 
in amended claim 1, the message and pixel are transmitted back to the server when the message 
is opened, where the encrypted hash of the message is added, which is then transmitted to the 
sender. In Barkan, server 3 adds a new symmetrical key (page 29, lines 12-15), a CRC section 
43 (page 30, line 1), a sender identification section 44 (page 30, line 2), a recipient identification 
section 45 (page 30, line 6) and a message identification number 46 (page 30, lines 7-10). 
Barkan's server 3 then sends the message, along with the key, CRC etc., to user 2. 

Barkan then states "user 2 reads his/her E-mail for the mailbox 22, through link 21. 
There is an indication that a registered E-mail message arrived which addressed to user 2, and 
number to identify the message with the server" (page 30, lines 16-19). The message itself is 
still not opened, rather, user 2 merely sees that he has a registered email in his system. Indeed, 
Barkan specifically states: "User 2 however, cannot read the message or find the identity of the 
sender." (page 31, line 1). 

Barkan goes on to state that "User 2 is given the choice of either to accept or not to accept 
the registered mail." Note, user 2 still has not opened the email. 

If user 2 declines to accept the message, then the message is deemed to be not delivered, 
and notice of such non-delivery may be sent to the first user (page 3 1 , lines 5-10). The message 
has still not been opened by user 2. 

Only if user 2 accepts the message is there further processing. Barkan states: "the 
computer of user 2 prepares a response message as follows: the whole message or only a hash of 
the message or a CRC thereof is encrypted using a public key method, with the private key of 
user 2. . . . This encryption by user 2 serves as the signature of user 2 to the effect that he/she 
agrees to accept the registered E-mail message" (page 31, lines 12-18) Note, this action takes 
place at the computer of user 2, not at server 3. 

As stated by Barkan, "user 2 [then] sends the encrypted messaged prepared as detailed in 
f(2) above to server 3 through link 23 (see Fig. 1) (page 32, lines 8-9). Server 3 then "decrypts 
the message . . . using the public key of user 2. The decrypted message is compared with the 
message sent to user 2, as illustrated in FIG. 3. If the two are identical, this is proof that user 2 
agrees to receive the registered E-mail message" (page 32, lines 13-15). Where the messages are 
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identical, "Mail server 3 sends the second symmetrical key to user 2, see Fig. 3. This enables 
user 2 to open the registered mail message" (page 32, lines 17-18). Note, the user may now be 
able to open the message because he has been sent the appropriate key, but there still is no 
indication that user 2 has actually opened the message. 

Barkan then states: "Mail server 3 also sends to user 1 a message including the encrypted 
message from user 2, see Fig. 4, concurrently with the transmission of the second symmetrical 
key to user 2" (page 33, lines 1-3). Note, the message is still not opened, and the encrypted 
message (as detailed in Fig. 4 of Barkan) sent to user 1 is only proof, according to Barkan, that 
user 2 agreed to accept the registered message (See, page 31, lines 12-20). Thus, this message is 
not an indication that the message was opened, as recited by amended claim 1 . 

Barkan does describe the steps necessary to open the email by user 2 on pages 33, line 13 
to page 34, line 8. However, nowhere within this section is there any teaching or suggesting that 
a further message is sent from user 2, or server 3, to user 1 indicating that the message was 
actually opened by user 2. Indeed, Barkan merely states that: "User 1 has proof that the message 
was delivered to its destination" (page 34, line 9)(emphasis added). Delivery of a message is not 
the same as opening the message. Applicant's amended claim 1 provides an indication that the 
message was actually opened. 

Similar processes are set forth in the other methods described by Barkan. Barkan's 
Method 1 describes using the public key of user 2 to encrypt an email. There is no discussion of 
providing an indication to user 1 that user 2 actually opened the email. 

Barkan's Method 2 is directed to processes that occur at the email systems of user 1 and 
user 2. While Barkan does state that: "the E-mail program at the second user automatically 
decrypts the second message with the private key of the second user 2, presents the decrypted 
message to the second user 2, prepares a third message include a receipt for the second message 
signed with the private key of the second user 2, and sends the third message to the E-mail 
address 12 of the first user" (page 19, lines 9-14), this method does not teach adding a pixel at a 
server displaced from a recipient or transmitting the message from the recipient to the server, 
including the pixel for indicating the opening of the message at the recipient, when the message 
is opened at the recipient, as is recited by amended claim 1 . 



-12- 



Appl.No. 10/722,238 
Client ID/Matter No. RPOST-66230 



Method 3 disclosed by Barkan on pages 22-27 is similar to that of Method 2, in that all of 
the process set forth are performed on the computers of user 1 or user 2. None of the processes 
are described as being carried out on a server displaced from a recipient, as claimed in amended 
claim 1 . Nor is there is any teaching or suggestion of transmitting the message from the recipient 
to the server, including the pixel for indicating the opening of the message at the recipient, when 
the message is opened at the recipient, as is recited by amended claim 1 . 

Barkan's Method 4 has already been discussed above, as this is the Method cited by the 
Examiner in the Office Action. Barkan's Method 5 is an automated version of Method 4. All of 
the discussion related to Method 4 above applies equally to Method 5. Methods 6-9 add 
additional complexity or automation to Method 4. Similarly to the discussion of Method 4 
above, none of Methods 5-9 teach or even suggest adding a pixel to the message at a server 
displaced from the recipient or transmitting the message from the recipient to the server, 
including the pixel for indicating the opening of the message at the recipient, when the message 
is opened at the recipient, as is recited by amended claim 1 . 

For all of the reasons above, Applicant respectfully submits that amended claim 1, and its 
dependent claims, are patentable over the cited art and respectfully request that the rejections be 
withdrawn and that claims 1-6 be allowed. 

Claims 7-18 were rejected under 35 U.S.C. 103(a) as being unpatentable over Barkan and 
Ouchi (U.S. Patent No. 5,978,836). Applicant respectfully traverses this rejection. 

Claims 7 and 13 have been amended to recite the step of transmitting a message from a 
server to a recipient through a network including at least one interim station network station 
unknown to the sender at the time the message is transmitted, the message including a pixel for 
indicating the opening of the message at the recipient. As discussed previously, neither Barkan 
nor Ouchi teach or even suggest including a pixel for indicating the opening of a message at a 
recipient in the message at a server before the message is transmitted to the recipient, as is 
claimed in independent claims 7-13. 

Further, Ouchi teaches a system directed towards obtaining sequential review and 
approvals of forms. Apparently the Examiner is construing a list of email addresses as described 
by Ouchi as being equivalent to the interim stations through which an email travels when it is 
transmitted through the internet, as is described, and claimed, by Applicant. Even though 
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Applicant is confident that one skilled in the art would not find the email list of Ouchi to be 
equivalent to the list of interim stations through which a message travels when it is routed 
through the internet, Applicant has amended claim 7 and claim 13 to recite that the message is 
transmitted through a network including at least one interim network station that is unknown to 
the sender at the time the message is sent to clarify this distinction. 

Operation of the Ouchi system requires a SQL database of addresses that is accessed by a 
route manager to route a message to multiple addressees. To do this, the message must be 
returned to the route manage which then determines which addressee to send the message to 
next. Thus, Ouchi requires that the "stations", as that term has been interpreted by the Examiner 
in view Ouchi, must be known to the sender before the message is sent. 

This is completely different from the method claimed by Applicant in claims 7 and 13. 
Rather, Applicant's method receives an attachment that contains a list of the interim stations that 
a message has passed through on a network on its way to and from an intended recipient of a 
message. The identity of those interim stations is not known to the sender before the message is 
sent, but rather are a result of the network routing of the message. Those skilled in the art of 
network communications understand that when a message is sent over a network, the message 
may pass through many nodes, or routers, on the network on its way to and from and recipient. 
Moreover, using the internet, it is common that an individual message is divided into packets, 
and that each packet may take a different route to a destination, where the message is 
reconstituted. None of these steps are taught or even suggested by any of the art cited, taken 
alone or in combination. For these reasons, Applicant respectfully submits that claims 7 and 13, 
and the claims dependent therefrom, are patentable over the cited art, and requests that the 
rejections be withdrawn and the claims allowed. 
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CONCLUSION 

Applicants have carefully reviewed the arguments presented in the Office Action and 
respectfully request reconsideration of the claims in view of the remarks presented. In light of 
the above amendments and remarks, Applicants respectfully request that a timely Notice of 
Allowance be issued in this case. 

Should the Examiner have any questions concerning the above amendments and 
arguments, or any suggestions for further amending the claims to obtain allowance, Applicants 
request that the Examiner contact Applicants' attorney, John Fitzgerald, at 310-242-2667. 

The Commissioner is authorized to credit any overpayment or charge any additional fees 
in this matter to our Deposit Account No. 06-2425. 

Date: July 14, 2008 Respectfully submitted, 

FULWIDER PATTON LLP 
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John K. Fitzgerald, Reg. No. 38,881 
Registration No. 38,881 
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